Skip to main content Skip to complementary content

Setting advanced properties

In the Advanced tab, you can configure CDC-related options as well as any additional settings or internal parameters that may be required.

Select either Trigger-based CDC or Log-based CDC according to your preferred CDC method.

Information note

Switching between Trigger-based CDC and Log-based CDC (or vice versa) will require you to reload the target.

Trigger-Based CDC

  • Create CDC artifacts: When this option is enabled (the default), Replicate creates the required CDC artifacts in the source database. Clear this check box if you would rather create the CDC artifacts manually.
  • Create CDC table in schema: The name of the schema in the source database where you want the attrep_cdc_changes table to be created.

    Information note

    The specified schema must already exist in the source database.

  • Log cleanup interval (min): Specify how often (in minutes) to check if Change Records need to be deleted from the attrep_cdc_changestable.
  • Log retention period (min): Specify how long (in minutes) to keep Change Records in the attrep_cdc_changes table before deleting them.
  • Transactional consistency (sec): By default, the longest supported transaction length is 60 seconds. If you have transactions in your environment that exceed 60 seconds, you should set this value to the expected transaction duration. Note, however, that the longer the transaction, the greater the latency will be.
  • Use log table: When this option is enabled, during the task, Replicate copies the changes from the attrep_cdc_changes table to the attrep_cdc_log table. This is the preferred method of working as it significantly reduces latency. In order to use this option, you must first perform the following procedure:

    1. Stop all tasks configured with a SAP HANA source endpoint.
    2. Back up the attrep_cdc_changes table.
    3. In following script, replace $SCHEMA$ with the artifact’s schema:

       

      ; Create the attrep_log_table CREATE COLUMN TABLE "$SCHEMA$"."attrep_cdc_log"( "CHANGE_ROWID" BIGINT CS_FIXED, "CHANGE_INDX" BIGINT CS_FIXED, "CHANGE_EVENT_TIME" LONGDATE CS_LONGDATE, "COPY_TIME" LONGDATE CS_LONGDATE, "OPER" CHAR(1) CS_FIXEDSTRING, "TBL_DB_ID" BIGINT CS_FIXED, "PK_0" NVARCHAR(5000), "PK_1" NVARCHAR(5000), "PK_2" NVARCHAR(5000), "PK_3" NVARCHAR(5000), "PK_4" NVARCHAR(5000), "PK_5" NVARCHAR(5000), "PK_6" NVARCHAR(5000), "PK_7" NVARCHAR(5000), "PK_8" NVARCHAR(5000), "PK_9" NVARCHAR(5000), "PK_10" NVARCHAR(5000), "PK_11" NVARCHAR(5000), "PK_12" NVARCHAR(5000), "PK_13" NVARCHAR(5000), "PK_14" NVARCHAR(5000), "PK_15" NVARCHAR(5000), "PK_16" NVARCHAR(5000), "PK_17" NVARCHAR(5000), "PK_18" NVARCHAR(5000), "PK_19" NVARCHAR(5000), PRIMARY KEY ("CHANGE_ROWID")); ;Copy all changes from attrep_cdc_changes table to the attrep_cdc_log table INSERT INTO "$SCHEMA$"."attrep_cdc_log" ("CHANGE_ROWID","CHANGE_INDX","CHANGE_EVENT_TIME","COPY_TIME","OPER","TBL_DB_ID", "PK_0", "PK_1", "PK_2", "PK_3", "PK_4", "PK_5", "PK_6", "PK_7", "PK_8", "PK_9", "PK_10", "PK_11", "PK_12", "PK_13", "PK_14", "PK_15", "PK_16", "PK_17", "PK_18", "PK_19") (SELECT "$rowid$","INDX","EVENT_TIME",CURRENT_TIMESTAMP,"OPER","TBL_DB_ID", "PK_0", "PK_1", "PK_2", "PK_3", "PK_4", "PK_5", "PK_6", "PK_7", "PK_8", "PK_9", "PK_10", "PK_11", "PK_12", "PK_13", "PK_14", "PK_15", "PK_16", "PK_17", "PK_18", "PK_19" FROM "$SCHEMA$"."attrep_cdc_changes" ORDER BY "$rowid$"); ;DELETE all changes from attrep_cdc_changes table DELETE FROM "$SCHEMA$"."attrep_cdc_changes" WHERE "$rowid$" IN (SELECT "CHANGE_ROWID" FROM "$SCHEMA$"."attrep_cdc_log"); ; COMMIT the changes COMMIT;
    4. Run one script operation at a time with auto-commit off.

      Information noteThe duration of the script job will depend on size of the “attrep_cdc_changes” table.
    5. Verify the following:

      • The attrep_cdc_log table has been created in the artifact’s schema.
      • The attrep_cdc_changes table is empty.
      • The attrep_cdc_changes table content has been successfully copied to the new attrep_cdc_log table.

    6. Resume your tasks.
  • SAP archiving users to filter: Specify the user names of SAP application users whose DELETE operations you do not want Replicate to capture. Users must be separated with commas.

    Information note

    Editing the user list requires you to stop and then resume the task for the changes to take affect.

Log-based CDC

Log-based CDC is faster than Trigger-based CDC and has a smaller system footprint. When Log-based CDC is selected, Replicate will read the changes directly from the SAP HANA logs. In order for Replicate to be able to do this, you need to specify the location of the logs in the Redo Log Shared Folder and Backup Log Shared Folder fields respectively (both fields are mandatory).

If Replicate Server is not installed on the SAP HANA machine, the redo logs and backup logs must reside in Shared Folders on the SAP HANA machine.

Log Access Preferences

You can determine which logs Replicate will read the changes from. If the logs are encrypted, you also need to provide the encryption settings as described in Encryption Settings below.

From the Read changes from drop-down list, select one of the following:

  • Prioritize backup log - This is the default mode as it provides best performance while also offering greater efficiency. In this mode, Replicate will first try to capture the changes from the backup log. If the changes do not exist in the backup log, it will try to capture them from the online redo log instead.

    When this option is selected, you also need to specify the locations of the Redo log shared folder and the Backup log shared folder.

  • Backup log only - In this mode, Replicate requires access to the backup log only. Changes will be captured from the backup log as soon as they become available. The backup interval and the size of the backup files will impact the capture time.

    When this option is selected, you also need to specify the location of the Backup log shared folder.

  • Redo log only - This mode should not be used in production environments. In this mode, Replicate requires access to the redo log only. Changes will only be captured if they exist in the redo log. In the event that the changes are not available in the redo log, the task will need to be reloaded to ensure that all data and changes from the source are available on the target.

    When this option is selected, you also need to specify the location of the Redo log shared folder.

Encryption Settings

Replicate can decrypt encrypted redo logs and backup logs. The encryption root keys can either be retrieved automatically by Replicate or provided by the user in the designated fields.

  • Automatically retrieving the encryption root keys - This method is preferable when the encryption root keys frequently change or if the encryption root key backup files are not accessible from the Replicate machine. This method also requires the Replicate user to be granted the ENCRYPTION_ROOT_KEY_ADMIN permission (for retrieving the encryption root keys).
  • Manually providing the encryption root keys - This method is preferable when the encryption root keys rarely change and when the encryption root key backup files are accessible from the Replicate machine. This method may also be preferable for organizations that do not want to grant the ENCRYPTION_ROOT_KEY_ADMIN permission to the Replicate user.

The following settings are available:

Information note

Depending on your preferred method of providing Replicate with the encryption root keys (automatically or manually), some of the settings may not be relevant.

  • Encrypted redo log - Select this option if the redo logs are encrypted. If you need to manually provide the encryption root keys, specify the path of the redo log encryption root key backup file in the Log root key backup (.rkb) file field. Otherwise, leave this field empty.
  • Encrypted backup log - Select this option if the backup logs are encrypted. If you need to manually provide the encryption root keys, specify the path of the backup log encryption root key backup file in the Backup root key backup (.rkb) file field. Otherwise, leave this field empty.
  • Root key backup password - The password for reading the root key backup files.

Internal parameters

Internal parameters are parameters that are not exposed in the UI. You should only use them if instructed by Qlik Support.

To add internal Qlik Replicate parameters:

  1. Click the Internal Parameters link.

    The Internal Parameters dialog box opens.

  2. In the edit box, type the name of the parameter you need to add and then click it.
  3. The parameter is added to the table below the search box with its default value.
  4. Change the default value as required.
  5. To reset the parameter value to its default, click the "Restore default value" icon at the end of the row.

More options

These options are not exposed in the UI as they are only relevant to specific versions or environments. Consequently, do not set these options unless explicitly instructed to do so by Qlik Support or product documentation.

To set an option, simply copy the option into the Add feature name field and click Add. Then set the value or enable the option according to the instructions you received.

Settings summary

You can view a summary of your settings by clicking the Setting Summary link. This is useful if you need to send a summary of your settings to Qlik Support.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!